Ham Radio 2000 #1

home *** CD-ROM | disk | FTP | other *** search

/ Ham Radio 2000 #1 / Ham Radio 2000.iso / ham2000 / packet / ms_exe / msrel.eng < prev next >

Wrap

Text File | 1994-12-18 | 18.5 KB | 373 lines

Subject: Meteor Scatter in Packet Radio From : Pino Zollo I2KFX This paper has been sent to few magazines in Europe for publication. The software is available on request. Report on Meteor Scatter experiments using Packet Radio at 144 MHz ABSTRACT In this paper I will describe the experiments done by I2KFX and I0VUQ of Meteor Scatter QSO's using Packet Radio with 2 phase PSK modulation at 1200 Baud. INTRODUCTION The idea of using digital techniques for Meteor Scatter communications is not original of Radio Amateurs. Since many years, infact, there are in service civil and military systems that use these technique for disseminating short messages on wide geographical areas. (1) The advent of packet radio has allowed the pratical extention of this technique to radio amateurs, givig to anybody, provided with a minimum of equipment, the possibility to venture upon this fascinating activity in the past reserved only to the most powerfull stations end with very patient operators. The AX.25 protocol was not borne for Meteor Scatter activity, it was necessary, so, some adaptation and simplification to allow frames to met meteors beams and be reflected to ground. With these ideas I started, last year, to write a program for PC able to drive a KISS TNC and implement all the actions that are more suitable for the MS technique. In my previous article on DUBUS 3/88 I reported the details. Here I will summarize all the procedures for the benefit of who is new to meteor scatter. Every day our planet is run over by tons of debris of different dimensions arriving from deep space. When these debris come into the atmosphere they disintegrate generating a cylinder of ionized air. This cylinder will last from few milliseconds to some minute depending on the size of the stone, and it will reflect radiowaves in the range from 30 MHz to low UHF. We don't know the exact moment of arrival of meteors and the right position in the sky of the ionized cylinder, so we have to transmit continuously in certain windows of time agreed with the other station. For Packet Radio Meteor Scatter we have always used 15 seconds windows in our experiments up to now, but the program allows also 30 second windows. Ionized air cylinders appear in the range 80 .. 110 Km. Because of the geometry of the earth they allow QSO's up to 2000 Km. It does not exist a minimum distance. For distances lower than 500 Km the antennas should irradiate also on the back to take advantage of meteors appearing on the back . Papers (2) and (3) report considerations about the geometry. I was saying that meteors arrive suddenly, but something can be known in advance: few hundreds of trails have been catalogued by astronomers and we know the point in the sky from where they appear to come out, we know, besides, the period of days in which they arrive into the atmosphere. (on DUBUS you can find all these informations) A special program in BASIC by DL5MCG allows to compute the best period of the day for a QSO between two stations. During these periods meteors arrive almost perpendicular to the path between the two stations. We saw that for doing a QSO we have to transmit continuously hoping that meteors arrive and bounce the messagge to the other station. To do this I wrote a program in Turbo Pascal that menages all the operations. In practice the program sends to the TNC, in KISS mode, the message to be transmitted so many times as they fit in the time window in use. In the experiments we have always used a 15 seconds window. A station transmits in the first 15 seconds of the minute, then goes in receiving mode. The other station transmits in the others 15 seconds and so on. EXPERIMENTS Since the mid of May '89 I0VUQ and I have started a series of tests to verify the possibility of QSO's using small powers and minor Meteor Showers. Here follows the description of the experiments, the successes and the difficulties that we met and the perspectives of future development of this activity that tries to implement the synergy between digital techniques and DX in VHF. Following the publication on DUBUS and on Radio Rivista of my article of presentation of the program MS for PC, many OM's were interested to start experiments. The first station that was ready was the one of Alessandro, I0VUQ, located in S.Maria Le Mole JN61hs south of Rome. Alessandro's station is made of a PC, a TNC2 with EPROM 1.1.6, an axternal PSK modem (JARL design). The TX is an IC202 that drives a 50 W linar amplifier equipped with a QQE06/40. A TS820 is on the receiving side together with a Datong UC/1 converter. The antenna is a 9+9 crossed yagi, the same used for Oscar 13. My station in Monza (JN45po) is made of a PS2/30, a PK80 with EPROM 1.1.4 with KISS loader and an external PSK modem. The TX is an FT201 with an home made transverter that drives a Fisher linear amplifier. The output power was 80 W due to the old tube. The RX is a Drake R4B and a preamplifier home made with N.F. of 0.9 dB. Antennas are 2 9+9 crossed yagis coupled with hibrid rings. Both station use right circular polarization. The distance between our stations is 507 Km, and the path is all over the Appennini chain of mountains. Before starting tests in 144 Mhz we did verify that all the hardware were ok, so we made qso's on 20 m and also on 40 m when the 20 m were closed. By the way we found that PSK modulation was excellent even in the mess of the 40 m. After having verified that all the hardware was right, doubting to be able to make a qso in MS with only 50 W, Alessandro moved his digital equipment to the site of the friend I0NLK. I0NLK does EME with 4 yagis 20 el. and 500 W. With these conditions we made the first try, but we were not lucky: there was tropo scatter that day. I0VUQ did decode first a packet, and later we could even exchange few words in SSB. After that time we have always operated from our station and we have not found Tropo any more. In the meantime I had problems with my frequency counter locked to the local Medium Waves station. The major difficulties that I have met at the beginning have been related just at the measure of the output frequency. The PSK modem has a locking band of + or - 100 Hz. If signals are weak, on the contrary, we need a better precision: let say + or - 30 Hz. We must also take in account the error fo the other station that could be in the opposite direction. To have such a precision and stability is not so easy not having a synthesized equipment as it is in my case. First of all it takes to measure the effective output frequency sending at the microphone input a 1600 Hz tone not modulated. Not having professional instruments it remains only to use a standard frequency extracted from a very stable radio emission. Here in Italy our MW and TV RAI stations are controlled by a cesium reference oscillator. An other problem is the natural drift of both RX and TX. In my case I need to warm up at least for a couple of hours all my equipments. Later, during operations, I verify every half an hour that frequency is still correct, and eventulally I adjust for the drift. But let's see the tests ! After having missed many appointments with major showers due to QRL, finally on saturday 13th of May we can do a test on the Nu Puscidis, a shower that arrives around the middle of the day. Nu Pischidis are a poor shower, but we did try as well. After one hour from the beginning of transmissions we were starting to get discouraged. I made a phone call to Alessandro for askig if he had heard something. The answer was negative, but we decided to go ahead for an other hour. Few minutes later, non knowing what to do meanwhile the PC was regularly transmitting every 15 seconds, I concentrated my attention to the receiver and I heard a strange fluctuating noise. it was similar to F1 racing cars on the track: uouu uouu...what could it be ? I tried to move the tuning knob of the Drake and suddenly the green LED of the demodulator indicated a lock. Almost immediatelly I heard the printer working. A rapid adjustment of the tuning and others printed lines. You can imagine my happiness ! it was the first message. I0VUQ=>I2KFX UI Odd 8 <240>: cq ms It was 11:01 o'clock. I call at the telephone Alessandro and I read the message to him. During the conversation the printer continues to work. At this point the QSO had to be finished. Also I0VUQ had to receive my signals. We did continue transmissions but he didn't receive anything. In the meantime I check the frequency moving the TX on the RX: it was 140 Hz lower. Later we discovered that the HP counter of Alessandro had not been calibrated since long time so its reading was slightly wrong. After that day we made others attempts: on the 20th and 21st of May on the Omicron Cetidis and on the 4th of June on the Arietids. In all these tests I have received lots of frames but none of mine had been received by Alessandro. Following this asymmetric behavior we started to analyze the phenomena. First of all, during first tries I0VUQ had no preamplifier. The signal I used to receive were normally around S1: this means that I was at the limit of the sensitivity of my station. An other matter to take in account is the geographical position. I0VUQ points his antennas towards Rome, so he loads all the noise produced bye the town; on the contrary I point East of Milan so my idle noise is much lower. In the test of the 4th of June Alessandro did use a preamplifier of unknown quality at the bottom of the cable and did modify the connection between the two antennas using an hibrid ring instead of the T connection, nevertheless he could just hear some signal from me, but no frame was correctly decoded. On the 11th of June we made another test fron 11:30 in the morning to 16:00 in the afternoon trying to exploit both the Arietids and the Zeta Persidis. Frames did start to arrive with a certain advance respect to computed times: at the beginning one or two frames in each window, later in big quantities. At the 12:41 a shower did transport 88 frames with the message "CQMSPSK", but unfortunately nothing in the opposite direction Monza-Roma. During this test I0VUQ did change his linear amplifier getting 100 W instead of the previous 50 W. He did also use a preamplifier but installed in the shack at the bottom of the cable. (weather was not good for climbing the tower) In the meanwhile I started to modify the program MS: the first version was in Turbo Pascal 3.0, but, shortly after having started tests on air I acquired the new version 5.0 of the same Turbo Pascal. The conversion from 3.0 to 5.0 was quite long and painful because of many subtle differences between the two compilers. Tests had showed the need of recording on the printer and on file all the received frames, so version 2.0 of MS did include such improvements. By the time JPI came out with a Modula-2 compiler at a very reasonable price and with very interesting characteristics. The main difference between Pascal and Modula-2, a part from the better syntax of the former, is that Modula-2 implements "Coroutines". Coroutines allow the implementation of really multitasking programs. In a multitasking program many "PROCEDURES" run at the same time ( depending on priorities ) and can exchange each other synchronization Signals. It was just the right language for MS as many activities have to be carried on at the same time. Of these 3 are the principal: i.e. - To receive and decode frames - To edit a new message for transmission - To run the clock that starts transmissions. As I received the compiler from the States I begun immediatelly to learn its possibilities and both for didactic pourposes and for real operative needs I started to re-write totally MS changing completely its structure. The re-writing of MS was really a good school: the implemented improvements are really many, starting from a better hanling of the serial port: now avery character that arrives to the computer starts at interrupt a Modula-2 routine. The running clock isn't any more a TSR, but a normal Modula-2 procedure. Besides now there is a complete line editor for messages to be transmitted. The added features are the possibility to adjust the computer timer and the fact that every received frame is reported with the exact arrival time. This last feature is very useful to analyze the time distribution of arrival of frames in the receiving window. A detailed description of the program I will reserve it for a future paper if there will be interest in informatic techniques. But let's come back to the activities on the radio. Examinating the various possible reasons for the poor reception at Alessandro's site we considered also a defect on the PSK demodulator, so, during a travel to Milan for QRL, Alessandro took his TNC and Modem for a comparison with mine. Connecting the two modems to the same radio and supplying them with weak signals showed that my modem was quite more sensible than the Alessandro's one. A further analysis showed that just the decider circuit was not working properly: the heart of the demodulator. So we arrived to summer holidays and Perseids did pass meanwhile Alessandro was sailing in Grece and I was swimming on the Riviera. (but, you know, there is no pleasure with big showers !) Respective businnes engagements did keep us far from meteors until Sunday 22nd of October. It was the time of the Orionids, a small shower that has the good idea of arriving at sunrise which is also the time of maximum daily arrival of meteors. (3), (4) At 3 o'clock GMT we were already in the shack worming up the equipment. One hour and one half later we started the transmission with the usual procedure: 15 seconds window, I0VUQ on the ODD window, I2KFX on the even one. Output frequency 144.160 MHz. At 4:48:04 I receive the first correct frame. The printer was disabled for not awaking the family, but the file recording was up and running. Here follows the first frames received by I0VUQ. 4 :40:55 Even I2KFX=>I0VUQ UI 1 <F0> 73 Alex And here is my first frame: 4:48:4 Odd I0VUQ=>I2KFX UI 1 <F0> r73alex At 8:24:11 GMT I receive the last frame after 1450 others, when the transformer of my linear amplifier decided to surrender shortcircuiting the plate secondary with the screen grid one. The QSO was done !! But what was different from previous trials ? By sure on Sunday morning the noise produced by Rome is much lower than in working days, besides the Alessandro's demodulator had been revised. Furthermore the time was at sunrise. Later tests will confirm these suppositions. Just as axample here are the receved frames during a nice burst: 5:6:37 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso" 5:6:37 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso" 5:6:37 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso" 5:6:37 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso" 5:6:38 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso" 5:6:38 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso" 5:6:38 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso" 5:6:39 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso" Please, note the distribution of frames in the second: four frames in the 37° and three in the 38° when were transmitted about 6 frames per second. This shows how the mode can exploit very short openings. Hoping of having attracted your interest on this communication technique I invite all Meteorscatters to try. Remaining QRV for any help many 73 de I2KFX and I0VUQ Pino Zollo I2KFX Via Negrelli,21 20052 Monza ITALY tel. xx39.39.833431 E-Mail i2kfx@vnet.ibm.com i2kfx @ ik2xkb.ilom.ita.eu (1) Meteor-Burst communication bounce signals between remote sites. W.E. Day Electronics 29 Dec. 1982 (2) Communicating Via Meteor Burst at Short Ranges. J.A. Weitzen IEEE Trans. on Comm. N. 11 Nov. 87 (3) An Analysis of Meteor Burs Communications for Military Applications. J.O. Oetting IEEE Trans. on Comm. N. 9 Sept. 80 (4) Radio Propagation by Reflection from Meteor Trails. G.R. Sugar Procedings of the IEEE vol.52 Feb. 64